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The Development Cycle 



9 Extend 
o Fix 
» Port 




9 Compiles? 

9 Executes? 

9 Looks ok? 
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Natural Time Scales 

® Design 
9 Edit source 
9 Compilation 
9 Batch 

waiting in queue 
9 Execution 
9 Analysis 






Some observations 


o Risk grows with magnitude of implementation step 
» Magnitude of implementation step grows with cost of 
verification/validation 
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Some observations 


o Risk grows with magnitude of implementation step 
» Magnitude of implementation step grows with cost of 
verification/validation 


Conclusion: 

Optimize productivity by reducing cost of verification! 
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Outline 


Q Introduction 

^ Testing 

Q Testing Frameworks 
Q Test-Driven Development 
Q TDD and Scientific/Technical Software 
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Test Harness - work in safety 
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Test Harness - work in safety 


Collection of tests that constrain system 




o Detects unintended changes 
a Localizes defects 
o Improves developer confidence 

® Decreases risk from change 
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“The main thing that distinguishes legacy code from non-legacy code is 
tests, or rather a lack of tests.” 

Michael Feathers 

Working Effectively with Legacy Code 


Lack of tests leads to fear of introducing 
subtle bugs and/or changing things 
inadvertently. 

9 Programming on a tightrope 

This is also a barrier to involving pure 
software engineers in the development of 
our models. 



TDD - Testing - NCAR 


May 1, 2012 10 / 61 


Tom Clune (SSSO) 





Excuses, excuses ... 



9 Takes too much time to write tests 
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Excuses, excuses ... 



» Takes too much time to write tests 
9 Too difficult to maintain tests 
9 It takes too long to run the tests 
9 It is not my job 
9 "Correct" behavior is unknown 


http : // j ava . dzone . com/ art icles/unit-test-excuses 

- James Sugrue 
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Just what is a test anyway? 

Tests can exist in many forms 
o Conditional termination: 

IF (PA( I , J)+PTOP.GT. 1200. ) & 
call stop_model(’ ADVECM : 

® Diagnostic print statement 

print*, 'loss of mass = 

« Visualization of output 



Pressure diagnostic error ’ ,11) 


delta M ass 


Tempi Temp2 Difference 
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Analogy with Scientific Method? 


Reality 

Constraints: theory and data 
Formulate hypothesis 
Perform experiment 
Refine hypothesis 


Requirements 
Constraints: tests 
Trial implementation 
Run tests 

Refine implementation 


Tom Clune (SSSO) 


TDD - Testing - NCAR 


May 1, 2012 



Properties of good tests 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

« Isolating 

► Test failure indicates location in source code 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 

a Orthogonal 

► Each defect results in failure of small number of tests 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 
a Orthogonal 

► Each defect results in failure of small number of tests 

a Complete 

► Each bit of functionality covered by at least one test 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 
o Orthogonal 

► Each defect results in failure of small number of tests 
9 Complete 

► Each bit of functionality covered by at least one test 

9 Independent 

► No side effects 

► Test order does not matter 

► Corollary: cannot terminate execution 




TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 
o Orthogonal 

► Each defect results in failure of small number of tests 
9 Complete 

► Each bit of functionality covered by at least one test 
9 Independent 

► No side effects 

► Test order does not matter 

► Corollary: cannot terminate execution 
9 Frugal 

► Run quickly 

► Small memory, etc. 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 
o Orthogonal 

► Each defect results in failure of small number of tests 
9 Complete 

► Each bit of functionality covered by at least one test 
9 Independent 

► No side effects 

► Test order does not matter 

► Corollary: cannot terminate execution 
9 Frugal 

► Run quickly 

► Small memory, etc. 

9 Automated and repeatable 



TDD - Testing - NCAR 


May 1, 2012 15 / 61 


Tom Clune (SSSO) 



Properties of good tests 

a Isolating 

► Test failure indicates location in source code 
o Orthogonal 

► Each defect results in failure of small number of tests 
9 Complete 

► Each bit of functionality covered by at least one test 
9 Independent 

► No side effects 

► Test order does not matter 

► Corollary: cannot terminate execution 
9 Frugal 

► Run quickly 

► Small memory, etc. 

9 Automated and repeatable 
9 Clear intent 
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Anatomy of a Software Test Procedure 



Procedure testFooQ 
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Anatomy of a Software Test Procedure 



Procedure testFooQ 



testTrajectory() ! s 
a = 2.; t = 3. 
s = trajectory(a, t) 
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Anatomy of a Software Test Procedure 




testTrajectory() ! s = \at 2 
a = 2.; t = 3. 
s = trajectory(a, t) 


call assertEqual (9., s) 
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Anatomy of a Software Test Procedure 



Procedure testFooQ 



testTrajectory() ! s = \at 2 
a = 2.; t = 3. 
s = trajectory(a, t) 

call assertEqual (9., s) 

! no op 
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Anatomy of a Software Test Procedure 




testTrajectoryQ ! s = \at 2 


call assertEqual (9., trajectory (2. ,3.)) 
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o Testing Frameworks 

Q Test-Driven Development 
0 TDD and Scientific/Technical Sof 
Q Example 
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Testing Frameworks 


» Provide infrastructure to radically simplify: 

► Creating test routines (Test cases) 

► Running collections of tests (Test suites) 

► Summarizing results 

9 Key feature is collection of assert methods 

► Used to express expected results 

call a ssert Eq ua I ( 1 20 , f a ct o r i a I (5 ) ) 

9 Generally specific to programming language (xUnit) 

► Java (JUnit) 

► Pnython (pyUnit) 

► C++ (cxxUnit, cppUnit) 

► Fortran (FRUIT, FUNIT, pFUnit) 
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GUI - JUnit in Eclipse 
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Q Test-Driven Development 


DD ar 
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(Somewhat) New Paradigm: TDD 


Old paradigm: 

a Tests written by separate team (black box testing) 
« Tests written after implementation 
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(Somewhat) New Paradigm: TDD 


Old paradigm: 

» Tests written by separate team (black box testing) 
« Tests written after implementation 
Consequences: 

« Testing schedule compressed for release 
» Defects detected late in development ($$) 


New paradigm 

9 Developers write the tests (white box testing) 

9 Tests written before production code 
9 Enabled by emergence of strong unit testing frameworks 
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The TDD cycle 



focus on interface focus on algorithm 
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Benefits of TDD 
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Benefits of TDD 


® High reliability 
® Excellent test coverage 
® Always “ready-to-ship” 

® Tests act as maintainable documentation 

► Test shows real use case scenario 

► Test is maintained through TDD process 

® Less time spent debugging 
® Reduced stress / improved confidence 
® Productivity 
® Predictable schedule 
® Porting 

a Quality implementation? 
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Anecdotal Testimony 



» Many professional SEs are initially skeptical 

► High percentage refuse to go back to the old way after only a few days 
of exposure. 

a Some projects drop bug tracking as unnecessary 
a Often difficult to sell to management 

► "What? More lines of code?" 
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Not a panacea 
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Not a panacea 


» Requires training, practice, and discipline 
» Need strong tools (framework + refactoring) 

9 Does not invent new algorithms (e.g. FFT) 

► No such thing as magic 

9 Maintaining tests difficult during a major re-engineering effort. 

► But isnt the alternative is even worse?!! 
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O TDD and Scientific/Technical Software 
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The Challenge of Technical Software 


» Serious objections have been raised: 
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The Challenge of Technical Software 



» Serious objections have been raised: 
► Difficult to estimate error 

* Roundoff 

* Truncation 
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Software Testing vs Science/Validation 



Software tests should only check implementation. 

» Only a subset tests will express external requirements (i.e. 
implementation independent) 

» Other tests will reflect implementation choices 

® Use "convenient" input values - not realistic values 
Consider tests for an ODE integrator implemented with RK4 

« A generic test may be for a constant flow field - any integrator should 
get an "exact” answer 

o A RK4 specific test may provide an artificial "flow field” that returns 
the values l.,2.,3.,4. on subsequent calls independent of the 
coordinates 
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Do test 

9 Proper jj of iterations 
9 Pieces called in correct order 

9 Passing of data between 
components 

Do NOT test 

9 Calculations inside components 




Initialize 




E 

F 


Atmopshere 


*1 


Ocean 




Land Ice 


c 


Finalize 




Much easier to do in practice with objects than with procedures. 
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Numerical Tolerance 


For testing numerical results, a good estimate for the tolerance is 
necessary: 
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Numerical Tolerance 



For testing numerical results, a good estimate for the tolerance is 
necessary: 

a If the tolerance is too low, then the test may fail for uninteresting 
reasons. 
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necessary: 
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reasons. 
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Numerical Tolerance 



For testing numerical results, a good estimate for the tolerance is 
necessary: 

® If the tolerance is too low, then the test may fail for uninteresting 
reasons. 

o If the tolerance is too high, then the test may have no teeth 
Unfortunately ... 

o Error estimates are seldom available for complex algorithms 

9 And of those, usually we just have an asymtotic form with unknown 
leading coefficient! 
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Numerical tolerance (cont’d) 
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Numerical tolerance (cont’d) 



Observations 
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Numerical tolerance (cont’d) 



Observations 

Q machine epsilon is a good estimate for most short arithmetic 
expressions 
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Numerical tolerance (cont’d) 



Observations 

Q machine epsilon is a good estimate for most short arithmetic 
expressions 

Q large errors arise in small expressions in fairly obvious places (1/A) 
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Numerical tolerance (cont’d) 



Observations 

Q machine epsilon is a good estimate for most short arithmetic 
expressions 

Q large errors arise in small expressions in fairly obvious places (1/A) 

Q larger errors are generally a result of composition of many operations 
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Numerical tolerance (cont’d) 



Observations 

Q machine epsilon is a good estimate for most short arithmetic 
expressions 

Q large errors arise in small expressions in fairly obvious places (1/A) 

Q larger errors are generally a result of composition of many operations 

Conclusion: If we write software as a composition of distinct small 
functions and subroutines, the errors can be reasonably bounded at each 
stage 
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TDD and long integration 


» TDD does not directly relate to issues of stability 
o If long integration gets incorrect results: 
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» TDD does not directly relate to issues of stability 
o If long integration gets incorrect results: 

Q Software defect: missing test 
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TDD and long integration 


a TDD does not directly relate to issues of stability 
a If long integration gets incorrect results: 

Q Software defect: missing test 
Q Genuine science challenge 

a TDD can reduce the frequency at which long integrations are 
needed / performed 
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TDD and Lack of Analytic Results 



» Keep in mind: “How can you implement it if you cannot say what it 
should do?” 

o Split into pieces - often each step has analytic solution 
» Choose input values that are convenient 


Consider a trivial case: 

call assert Eq ua I ( 3 . 14 159265 , a r e a O f C i r c I e ( 1 . ) ) 
call assert Eq ua I ( 6 . 2 8 . . . , a r e a O f C i r c I e ( 2 . ) ) 

What if instead the areaOfCircle() function accepted 2 arguments: ‘V’ 
and r. 


call 

assertEqual ( 1 . , 

areaOfCircle 

(i- . 

!■)) 

call 

assert Equal (4. , 

a rea OfCi rcle 

(i- . 

2-)) 

call 

assertEqual (2. , 

a rea OfCi rcle 

(2. , 

!■)) 
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TDD and irreducible complexity 



a Are the tests as complex as the implementation? 
a Short answer: No 
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TDD and irreducible complexity 



» Are the tests as complex as the implementation? 
a Short answer: No 

a Long answer: Well, they shouldn’t be ... 
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» Are the tests as complex as the implementation? 
a Short answer: No 

a Long answer: Well, they shouldn’t be ... 

► Unit tests use specific inputs - implementation handles generic case 
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TDD and irreducible complexity 



» Are the tests as complex as the implementation? 

» Short answer: No 

o Long answer: Well, they shouldn’t be ... 

► Unit tests use specific inputs - implementation handles generic case 

► Each layer of algorithm is tested separately 
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TDD and irreducible complexity 



» Are the tests as complex as the implementation? 

» Short answer: No 

o Long answer: Well, they shouldn’t be ... 

► Unit tests use specific inputs - implementation handles generic case 

► Each layer of algorithm is tested separately 

► Layers of the production code are coupled - huge complexity 
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TDD and irreducible complexity 



» Are the tests as complex as the implementation? 

» Short answer: No 

o Long answer: Well, they shouldn’t be ... 

► Unit tests use specific inputs - implementation handles generic case 

► Each layer of algorithm is tested separately 

► Layers of the production code are coupled - huge complexity 

► Tests are decoupled - low complexity 
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TDD and the Legacy Burden 



» TDD was created for developing new code, and does not directly 
speak to maintaining legacy code, 
a Adding new functionality 

► Avoid wedging new loging directly into existing large procedure 

► Use TDD to develop separate facility for new computation 

► Just call the new procedure from the large legacy procedure 
9 Refactoring 

► Use unit tests to constrain existing behavior 

► Very difficult for large procedures 

► Try to find small pieces to pull out into new procedures 
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TDD Best Practices 
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TDD Best Practices 


» Small steps - each iteration <C 10 minutes 
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» Small steps - each iteration <C 10 minutes 
» Small, readable tests 

o Extremely fast execution - 1 ms/test or less 
9 Ruthless refactoring 
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TDD Best Practices 


» Small steps - each iteration <C 10 minutes 
» Small, readable tests 

o Extremely fast execution - 1 ms/test or less 
9 Ruthless refactoring 
9 Verify that each test initially fails 
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TDD and Performance 


» Optimized algorithms may require many steps within a single 
procedure 

a TDD emphasizes small simple procedures 
« Such an approach may lead to slow execution 
9 Solution: Bootstrapping 

► Use initial solution as unit test for optimized solution 

► Maintain both implementations 
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Experience to date 

TDD has been used heavily within several projects at NASA 

® Mostly for “infrastructure” portions - relatively little numerical alg 
® pFUnit 

® DYNAMO - spectral MHD code on shperical shell 
« GTRAJ - offline trajectory integration (C++) 

® Snowfake - virtual snowfakes; Multi-lattice Snowfake 




Observations: 

« ~ 1:1 ratio of test code to source code 
® Works very well for infrastructure 
« Learning curve 

► 1-2 days for technique 

► Weeks-months to wean old habits 

► Full benefit may require some sophistication 
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Q Introduction 
Q Testing 

o Testing Frameworks 
Q Test-Driven Development 
Q TDD and Scientific/Technical Software 

Q Example 

^ pFUnit 
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Linear Interpolation 
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Potential Tests 



a Bracketing: Find / such that x/ <= x < x/ + i 
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Potential Tests 


® Bracketing: Find / such that x/ <= x < x/ + i 
a Computing node weights: 



X-,+1 - X 

w a = 


Xi + 1 - Xi 

w b = 

1 - M/a 
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Potential Tests 


» Bracketing: Find / such that x ( - <= x < x/ + i 
o Computing node weights: 


x/+i - x 

w a = 

Xi + 1 - Xi 

w b = 1 - w a 


9 Compute weighted sum: y = w a f(x/) + w b f(x; + 1) 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


nodes x 

return 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


nodes x 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


nodes x 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

nodes x 

Postcondition 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 

at node 

{x} = {1, 2, 3} x = 2.0 

/ = 2 (?) 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

nodes x 

Postcondition 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 

at node 

{x} = {1,2,3} x = 2.0 

/ = 2 (?) 

at edge 

{x} = {1, 2, 3} x = 1.0 

/ = 1 (?) 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

nodes x 

Postcondition 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 

at node 

{x} = {1,2,3} x = 2.0 

/ = 2 (?) 

at edge 

{x} = {1,2,3} x = 1.0 

/ = 1 (?) 

other edge 

{x} = {1,2,3} x = 3.0 

/ = 2 (????) 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

nodes x 

Postcondition 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 

at node 

{x} = {1,2,3} x = 2.0 

/ = 2 (?) 

at edge 

{x} = {1,2,3} x = 1.0 

/ = 1 (?) 

other edge 

{x} = {1,2,3} x = 3.0 

/ = 2 (????) 

out-of-bounds 

{x} = {1,2,3} x = 1.5 

out-of-bounds error 
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Bracketing Tests 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

nodes x 

Postcondition 

return 

interior 

{x} = {1,2,3} x = 1.5 

/ = l 

other interior 

{x} = {1,2,3} x = 2.5 

/ = 2 

at node 

{x} = {1,2,3} x = 2.0 

/ = 2 (?) 

at edge 

{x} = {1,2,3} x = 1.0 

/ = 1 (?) 

other edge 

{x} = {1,2,3} x = 3.0 

/ = 2 (????) 

out-of-bounds 

{x} = {1,2,3} x = 1.5 

out-of-bounds error 

out-of-order 

{x} = {1, 2, 3} x = 1.5 

out-of-order error 
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Example: Bracketing Test 1 



« Preconditions: {x} = {1, 2, 3}, x = 1.5 
« Postcondition: return 1 
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Example: Bracketing Test 1 



« Preconditions: {x} = {1, 2, 3}, x = 1.5 
9 Postcondition: return 1 


subroutine test B r a c ket 1 ( ) 
nodes = [ 1 . , 2 . , 3 . ] 
index = get B r a c ket ( nodes , 1.5) 

call assert Eq ual ( 1 , index) 
end subroutine 
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Example: Bracketing Test 1 



« Preconditions: {x} = {1, 2, 3}, x = 1.5 
9 Postcondition: return 1 


subroutine test B r a c ket 1 ( ) 

call assert Eq ual ( 1 , get B r a c ket ( [ 1 . ,2. ,3.] , 1-5)) 

end subroutine 
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Example: Bracketing Test 1 



9 Preconditions: {x} = {1, 2, 3}, x = 1.5 
9 Postcondition: return 1 


subroutine test B r a c ket 1 ( ) 

call assert Eq ual ( 1 , get B r a c ket ( [ 1 . ,2. ,3.] , 1-5)) 

end subroutine 


function get B ra c ket ( nodes , x) r e s u 1 1 ( i n d ex ) 
index = 1 
end function 
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Example: Bracketing Test 2 



o Preconditions: {x} = {1, 2, 3}, x = 2.5 
9 Postcondition: return 2 

subroutine test B racket2 () 
nodes = [ 1 . , 2 . , 3 . ] 
index = get B ra c ket ( nodes , 2.5) 

call assert Eq ual (2 , index) 
end subroutine 


Tom Clune (SSSO) 


TDD - Example - NCAR 


May 1, 2012 50 / 61 



Example: Bracketing Test 2 



o Preconditions: {x} = {1, 2, 3}, x = 2.5 
9 Postcondition: return 2 

subroutine test B racket2 () 
nodes = [ 1 . , 2 . , 3 . ] 
index = get B ra c ket ( nodes , 2.5) 

call assert Eq ual (2 , index) 
end subroutine 


function get B ra c ket ( nodes , x) r e s u 1 1 ( i n d ex ) 
if (x > nodes(2)) then 
index = 2 
else 

index = 1 
end if 

end function 
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Example: Bracketing Test 2 



o Preconditions: {x} = {1, 2, 3}, x = 2.5 
9 Postcondition: return 2 

subroutine test B racket2 () 
nodes = [ 1 . , 2 . , 3 . ] 
index = get B ra c ket ( nodes , 2.5) 

call assert Eq ual (2 , index) 
end subroutine 


function get B ra c ket ( nodes , x) r e s u 1 1 ( i n d ex ) 
if (x > nodes(2)) then 
index = 2 
else 

index = 1 
end if 

end function 

Generalize ... 
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Example: Bracketing Test 2 



o Preconditions: {x} = {1, 2, 3}, x = 2.5 
9 Postcondition: return 2 

subroutine test B racket2 () 
nodes = [ 1 . , 2 . , 3 . ] 
index = get B ra c ket ( nodes , 2.5) 

call assert Eq ual (2 , index) 
end subroutine 


function get B ra c ket ( nodes , x) r e s u 1 1 ( i n d ex ) 

do i = 1, size(nodes) 1 

if (nodes(i+l) > x) index = i 
end do 

end function 
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Tests for Computing Weights 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


interval x 

weights 
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Tests for Computing Weights 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


interval x 

weights 

lower bound 

[l.,2.] x = 1.0 

w = [1.0, 0.0] 
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Tests for Computing Weights 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


interval 

X 

weights 

lower bound 

[1-5 2.] 

x = 1.0 

w = [1.0, 0.0] 

upper bound 

[1-2.] 

x = 1.0 

w = [0.0, 1.0] 
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Tests for Computing Weights 



index = b ra c ket ( nodes , 

X) 


Case 

Preconditions 

Postcondition 


interval 

X 

weights 

lower bound 

[1-5 2.] 

x = 1.0 

w = [1.0, 0.0] 

upper bound 

[1-2.] 

X = 1.0 

w = [0.0, 1.0] 

interior 

[1-2.] 

x = 1.5 

w = [0.5, 0.5] 
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Tests for Computing Weights 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

interval x 

Postcondition 

weights 

lower bound 

[1-5 2.] 

x = 1.0 

w = [1.0, 0.0] 

upper bound 

[1-2.] 

x = 1.0 

w = [0.0, 1.0] 

interior 

[1-2.] 

x = 1.5 

w = [0.5, 0.5] 

big interval slope 

[1-3.] 

x = 1.5 

w = [0.75,0.25] 
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Tests for Computing Weights 



index = b ra c ket ( nodes , 

X) 


Case 

Preconditions 

Postcondition 


interval 

X 

weights 

lower bound 

[1-5 2.] 

x = 1.0 

w = [1.0, 0.0] 

upper bound 

[1-2.] 

X = 1.0 

w = [0.0, 1.0] 

interior 

[1-2.] 

x = 1.5 

w = [0.5, 0.5] 

big interval slope 

[1-3.] 

x = 1.5 
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degenerate error 
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Tests for Computing Weights 



index = b ra c ket ( nodes , x) 


Case 

Preconditions 

Postcondition 


interval 


X 

weights 

lower bound 

[1-5 2.] 

X 

= 1.0 

w = [1.0, 0.0] 

upper bound 

[1-2.] 

X 

= 1.0 

w = [0.0, 1.0] 

interior 

[1-2.] 

X 

= 1.5 

w = [0.5, 0.5] 

big interval slope 

[1-3.] 

X 

= 1.5 

w = [0.75,0.25] 

degenerate 

[1-1 ] 

X 

= 1.0 

degenerate error 

out-of-bounds 

[1-2.] 

X 

= 0.5 

out-of-bounds error 
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Example: Weights Test 1 



o Precondition: [a, b] = [1., 2.],x = 1.0 
9 Postcondition: w = {1.0, 0.0} 

subroutine testWeight 1 ( ) 

real interval(2), weights(2) 

real : : x 

interval = [ 1 . , 2 . ] 

weights = com puteWeigh ts ( i n t e r v a I , 1.0) 

call assert Eq ual ([ 1 . 0 , 0 . 0] , weights) 
end subroutine testWeightl 

real function com puteWeights ( i n te rva I , x) r e s u 1 1 ( we i g h ts ) 
real , intent(in) interval(2) 
real, intent(in) :: x 
weights = [ 1 . 0 , 0 . 0] 
end function 
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Example: Tying it together 



o Precondition: 

► {(x,y),} = {(l,l),(2,l),(4,l)} 

► x = 3 

9 Postcondition: y = 1. 

subroutine testlnterpolateConstantY () 
real nodes (2, 3) 

nodes = reshape ([[1 ,1] ,[2 ,1] , [ 4 ,1]] , shape = [2,3]) 
call assertEqual ( 1 .0 , i n t e r p o I a t e ( nodes , 3.0)) 

end subroutine t est I n te r po I a t e 1 

function i n t e r p o I a t e ( nodes , x) 
real, intent(in) nodes ) 
y = 1 

end function interpolate 
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Example: Tying it together 



® Precondition: 


► {(x, y), •} = {(!, 1), (2, 3), (4,1)} 


► x = 3 

® Postcondition: y = 2. 

subroutine t e s 1 1 n t e r p o I a t e 1 ( ) 
real nodes (2, 3) 

nodes = reshape ([[1 ,1] ,[2 ,3] , [ 4 ,1]] , shape = [2,3]) 
call assert Eq ua I ( 1 . 0 , i n t e r p o I a t e ( nodes , 3.0)) 

end subroutine t est I n te r po I a t e 1 

function i n t e r p o I a t e ( nodes , x) result(y) 
integer : : i 

real weights(2), xAt End Points (2) , y At E n d poi n ts ( 2 ) 
i = getBracket ( nodes ( 1 ,:) , x) 

xAtEndPoints = nodes(l,i) / used derived type ? 
yAtEndpoints = nodes(2,i) 

weights = computeWeights ( nodes ( 1 , [ i , i +1] ) , x) 

y = sum(weights * yAtEndpoints) 
end function interpolate 
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Q Introduction 
Q Testing 

o Testing Frameworks 
Q Test-Driven Development 
Q TDD and Scientific/Technical Software 
O Example 

Q pFUnit 


Tom Clune (SSSO) 


TDD - pFUnit - NCAR 



pFUnit - Fortran Unit testing framework 


a Tests written in Fortran 
» Supports testing of parallel (MPI) algorithms 
9 Support for multi-dimensional array assertions 
9 Written in standard F95 (plus a tiny bit of F2003) 
9 Developed using TDD 


Tutorial in the afternoon sessioon 
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